@radarhere I agree that it would be preferable to use a time-of-compilation configuration flag to address this problem.

The problem I see with this approach is that it results in the -dynamiclib -install_name ... argument being specified twice during linking, and it's then up to the combination of compiler behavior and Makefile.in script usage as to whether the LDFLAGS or LDSHAREDFLAGS version is the one that takes effect. To my mind, that makes the solution fragile as any number of changes could cause the fix to break for non-obvious reasons.

If we can convinced zlib-ng maintainers to expose the install name as a direct configuration option, that would enable a much cleaner solution - but that obviously requires a patch upstream.

Interestingly, an iOS build requires patching some libraries, and multibuild has already been updated to support patching official sources. As a variant on this approach, it might be worth developing a macOS patch zlib-ng so we can explicitly specify an install name as part of the Pillow build, and then work to submit that patch upstream.

If we can convinced zlib-ng maintainers to expose the install name as a direct configuration option, that would enable a much cleaner solution

Ok, I've given it a try - zlib-ng/zlib-ng#1867